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I, Jay H. Connelly, hereby declare that: 

1 . I am the inventor of the above-captioned patent application and the 
subject matter described and claimed therein. 

2. Intel Corporation of Santa Clara, California, is the assignee of the above- 
captioned patent application. 

3. I was employed by Intel Corporation at the time the above-captioned 
patent application was filed. 

4. Prior to March 30, 1999, I conceived of the invention according to each of 
independent claims 1,7, 11, 15, 19, 23, and 27 of the above-captioned patent 
application (hereinafter "the present invention") in this country, as evidenced by Exhibit 
A. The date stamp, in unredacted form, shows that the concept identified in the 
document was written prior to March 30, 1999. 
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5. Exhibit A shows a screenshot produced by an application program called 
Ecco. Ecco is a personal information manager (PIM) application. Among other uses, 
Ecco may be used to record notes, which are automatically date-stamped when they 
are entered. The screenshot shows a set of notes corresponding to a "Patents" tab, 
which relates to a PIM object I set up in Ecco to save information pertaining to patent 
concepts and the like - thus producing a type of electronic patent notebook. The 
screenshot shows information pertaining to conception of the present invention, 
including purpose, advantages, key elements, and steps used to perform the method. 

6. I reduced the present invention to practice, with due diligence from a date 
prior to March 30, 1999 to March 22, 2000 (the filing date of the above-captioned patent 
application) in this country, as evidenced by Exhibit B. 

I hereby declare that all statements made herein of my own knowledge are true 
and that all statements made on information and belief are believed to be true; and 
further that these statements were made with the knowledge that willful false 
statements and the like are punishable by fine or imprisonment, or both, under Section 
1001 of Title 18 of the United States Code, and that such willful false statements may 
jeopardize the validity of the above-captioned application or any patent issued thereon. 
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The purpose of this invention is to define a mechanism for schedufing broadcast content based on the ag< 
users relevance information. S takes advantage of broadc ast economies of scale as weO as personal z at 
the highest level of relevant content for a given user base . 
o Advantages of current systems 

o Much higher percentage of users influence the schedule 

o current broadcast systems select content in advance, often based on a wsubsampling of the 
Neilson ratings, 
maximizes revenue for broadcast pipe 
o minimizes end user wait time subject to maximizing revenue 
o scalable across millions of users, 
o Self-refining 
o Key elements 

o A client system to measure preferences 

o A client system to deliver measurements to service provider 

o A server system to aggregate preferences across the user base 

□ A server system which broadcasts content based on the aggregate input from the user, 
o Can be combined with other relevance technology such as firefly 

o Steps 

o Initial broadcast content is sent out. The initial broadcast schedule is determined by legacy methods beyond the scope of this 

invention. For the case of video jukebox, this is likely based on historical data such as box office receipts, 
o A table of potential broadcast items is broadcast by the service provider and captured by each client system. For the case of 

video jukebox, this potential list of broadcast items also contains a set of meta data associated with each potential broadcast 

item since this is used in the rating algorithm, 
o Each client system rates the potential broadcast according to some mechanism. For example, this could be a combination of 

user input and inplicit inference as described in invention disclosure XYZ. 
o Each period (for example each night), each client sends updated feedback indicating the relevance of potential broadcast 

items. 

□ An aggregate table is created at the broadcast origination site indicating aggregated relevance values for each potential 
broadcast. 

o This table is sorted according to user relevance 

o Assume the the system has bandwidth and time to broadcast N cache lines. The top N items are scheduled for broadcast. 

□ in order to avoid stale relevance data, this table is destroyed after use and is re-created each day. That is, the relevance 
ratings are not aggregated over time. 
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LEGAL ID* Ufi'L- DATE: _12/19/97 Co/^ /A W^JllU , 

It is important to provide accurate and detailed information on this form. The information will be^sgoto 
evaluate your invention for possible filing as a patent application. When completed, please return this 
form to the Legal Department at JF3-147. If you have any questions, please call 264-0444 or 264- 
0998. 

_Jay H. 
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Last Name First Name ytsy^qUW Middle Initial 
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Supervisor'_Tony Baker WWID Phone _ 264-8397_ M/S: _ jf2-86 

(PROVIDE SAME INFORMATION AS ABOVE FOR EACH ADDITIONAL INVENTOR) 

4 Title of Invention: A signaling mechanism and apparatus t o provide content on demand in a broadcast system . 

3. What technology/product/process (code name) does it relate to: .Digital Entertainment Initiative _ 

4. Stage of development (i.e. % complete) 1 5 , _ 
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5. (a) Has a description of your invention been, or will it shortly be, published outside Intel: ^ ^ ^ 

NO* _X YES: DATE WAS OR WILL BE PUBLISHED: __ PATEN I Hatao 

If YES, was the manuscript submitted for pre-publication approval? YES: NO: : — y ufK /ABASE GROUP 

LE 6AL TEAM 



(b) Has your invention been used/sold or planned to be used/sold by Intel or others? 

N0: YES: X DATE WAS OR WILL BE SOLD: Q100 



(c) Does this invention relate to technology that is or will be covered by a SIG (special interest 
group)/standard/ or specification? 

NO: X YES: Name of SIG/Standard/Specification: 



(d) If the invention is a semiconductor device, actual or anticipated date of tapeout? 

(e) If the invention is software, actual or anticipated date of any beta tests. 2H/00_ 



6 Was the invention conceived or constructed in collaboration with anyone other than an Intel blue badge employee or in performance of 
a project involving entities other than Intel, e.g. government, other companies, universities or consortia? 

NO: X YES: Name of individual or entity: r s . — 



tt h a naae to this form, DATED AND SIGNED BY AT LEAST ONE PERSON WHO IS NOT A 
NAMED INVENTOR, to provide a description of the invention, and include the following information: 

1 Describe in detail how the invention works 

Th* nnrnose of this disclosure is to define a mechanism for providing content on demand in a broadcast 
Ivstem Thfc invention consists of a number of pieces. It is unclear which of the pieces are patentable 
fn the™ own right so they are all presented here together (let the lawyers help sort them out). 
Specifically, the system consists of: 

1 A mechanism for signaling and receiving meta data 

2 A mechanism for using meta data in a broadcast system to establish relevance 

3 a broadcast cache using a "consumable" policy. 

A A svstem which combines 1 -3 in order to provide content on demand. 

5*. A mechanism to use the above to automatically select content for broadcast 

These ideas were generated as part of the Video Jukebox investigation so we will use that example in 
the disclosure. 

Given the movement we are seeing in the industry, we need to sew up some of this IP as soon as 
possible. 

2 Mechanism for signalling and receiving meta data 

In oeneral meta data can be considered as a set of descriptors that describe a set of content to be 
Hp££d oJwa broadcast pipe. These descriptors provide the ability for the client systems to think, 

^^X^^^^ P° ssib,e br ° adcast content t0 be deHvered - Met \ data f ° rmS ^ 
basis for Intel's client side filtering, cache management and other personalization techniques. 

The signaling protocol involves sending proper signals such that the client systems can locate and 
IJaui e the ^broadcast content. This includes a new technique of pre-broadcast of the descriptors for 
uSomlna content Client systems capture and process this pre-broadcast information in order to 
determine when to receive content, where to receive content and which content to receive. 

21 Essential Elements for signaling and receiving meta data 

Scheduling service: Each client system contains a scheduling service which accepts requests to wake 
^rta sSdfc^ B. This service causes the system to wake up at a the specified t.me and select a 
soecifto serv ice This selection process can be via tuning to a specific frequency (as in ATSC or a DVB 
fr^wn^ert or'can be based on a set of data (such as multi-cast IP addresses) which defines a 
sS ? The exact scheduling service to be used is beyond the scope of this invention but is assumed to 

exist. 

Broadcast signalling. The broadcast server must be capable of producing 4 signals: 
Broadcast i sign H f pre -broadcast signal . A signal is emanated md.cat.ng when the content 
• descriptors will arrive. This signal must contain information indicating when the descriptors will 
arrive as well as information indicating how to access the content. 

2 " rnn1 ^n* H^crri ptnr hroadcast signal. A signal containing the content descriptors. This is sent 
' ; rr0 rdino to the specifics defined in the content descriptor pre-broadcast signal. 

3 a content pre- b roadcast signal . A signal indicating when the content will arrive along with 
selection information required to access the content. 



. 4 a rnntpnt hroadcast signal . This is a signal containing the actual broadcast content It is sent 
* according to and consistent with data contained in the content pre-broadcast signal. 

g iq n a l Bootstrap Service . Each client system maintains a signal bootstrap service that Ifctens to a well 
knnwnfrenuencv/address in order to identify upcoming services. For the case of DVB and ATSC 
SSSSmS^^IDO on a specific frequency. For the case of SAP, this could be the standard 
announcement port and IP address. 

2.2 Algorithm for signalling 
Figure 1 illustrates the signalling control flow diagram. 
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• Figure 1 : Signalling Control Flow Diagram 
2.2.1 Client application registers to receive signals from content provider X 

The client application registers with the client signaling system to receive signals from a specific content 
provider. The client signaling system maintains a table of applications associated with specific content 
providers. 

For example, consider an application that registers to receive signals from the Inteljilm service. The 
client signaling system maintains a table such as: 



Content Provider 


Application 


Service 


Intel film service 


lntel_film_application 


All services 



Table tbd: broadcast signal mapping table 



2.2.2 Content descriptor pre-broadcast is signalled 

A signal is sent over the broadcast system indicating some point in the future when content descriptors 
(meta data) is going to be sent. The client system has been listening (could be a well known port such 
as used by PSIP, DVBSi or SAP) for the upcoming service announcement. The system schedules itself 
to wake up at that time and records details associated with the event. 



For illustration purposes, assume that the following signal is formulated: 



Content Provider 


Event Description 


Time 


Frequency 


Selection details 


Intel filnvservice 


Content descriptor pre-broadcast 


11/10, 0400 


Channel 4 


IP:A.B.C.D 



The signal is sent over a weli known address such that each client can use this well known address. For 
example, it is sent over channel 4, IP address: T.B.D. Assume that each client system has a service 
which is listening to this address. 



2.2.3 Client system receives content descriptor pre-broadcast signal and wakeup is scheduled 
When the content descriptor pre-broadcast signal arrives, the registered application is notified. In this 
example the signalling system will wake up the lntel_film_application and will pass the pre-broadcast 
signal to'the application. The application will in turn schedule itself to be revived at 0400 on 1 1/10. 

2.2.4 The system wakes up and receives content descriptors 

The system wakes up at the pre-specified time and receives the content descriptors. These descriptors 
are stored in the local content descriptor table. The meta data is then processed to decide which content 
to receive (see relevance and caching discussion for more detail). The application interested in the 
specific content is notified and can process the content descriptors to determine which content it is 
interested in. 

2.2.5 Broadcast server sends content broadcast signal 

The broadcast server sends a signal indicating when the actual content will arrive. Each client system 
interested in receiveing more content schedules itself to wake up when the content arrives. 



For illustration purposes, assume that the following signal is formulated: 



Content Provider 


Event Description 


Time 


Frequency 


Selection details 


Intel film service 


Content broadcast 


11/10,0600 


Channel 4 


IP:A.B.C.D 



2.2.6 Client system receives content pre-broadcast signal and wakeup is scheduled 

" When the content broadcast signal arrives, the registered application is notified. In this example, the 
- ' signaling system will wake up the lntelJilm_application and will pass the broadcast signal to the 
application. The application will in turn schedule itself to be revived at 0600 on 1 1/10. 

2.2.7 Content is broadcast to the system 

The broadcast server then sends a set of content to all clients. Different clients will capture different 
content. The exact mechanism for selecting which content to capture is described in the section on 
relevance and cache management. The content is stored in the local cache for future, on-demand 
access. 

3 Broadcast content on demand using relevance and a local cache 

The purpose of the relevance and caching system is to allow clients in a broadcast system to maintain 
the most accurate cache of content for a specific domain. When combined with the signaling system 
(above), it allows each client to maintain its own set of content while allowing the broadcast system to 
only send out the actual content at specific times. 

Note that although this disclosure describes one possible relevance algorithm, any algorithm capable of 
inferring relevance based on pre-broadcast of meta tags would work. 

3. 1 Essential Elements for content on demand in a broacast system 

Each client system maintains a local meta table . The meta table might consists of 4 elements: 
1 .[Meta data attribute. This is a general class for grouping like meta data 

2.I Meta data value. This is the specific value for an attribute. The attribute combined with the value 
constitues a combination key and the value/attribute key is the main concept used for rating. 

3. Relevance Value. This is an indicator as to how relevant this attribute/value pair is for a given 
user. This is increased as the user expresses interest in a cache entry that has one of these 
attributes/value pairs in it and is decreased when the user indicates they do not want a cache 
item and the cache item has one of these attributes/value pairs in it. 

4. Believability. This is a weight factor to be applied to the specific attribute/value pair. It is 
increased when an element accurately predicts elements a user is interested in and decreased 
when a user is interested in an element but the relevance indicated they would not be. 

Entries in the meta table are constructed from the aggregation of all meta data associated with potential 
content and are updated based on explicit user requests as well as implicitly based on whether the user 
accesses the content or not. 

Content Rating Table . A content rating table is maintained to maintain state information about which 
content is available as well as which content will be available at a later date. It also indicates how likely 
a user is to consume a piece of content (either currently cached or potential). Each tuple contains: 
1 .. Name of the cache item. Used to describe the entry 

2. Rating value for this item. This rating value is either manually input by the user or implicitly 
calculated by processing meta data associated with the cache line. 

3. Rating treatment. This field either indicates 1) implicitly rate this line as things change or 2) 
explicit feedback was already provided, leave this rating alone. 

^-4. Cache status to indicate if this item is currently cached locally. 

5. Next treatment: used to track next actions to be taken for a given piece of content. In general, 
this is used to mark a currently cached item for deletion or a potential upcoming item for capture. 

The local cache is the first level cache. Its size should be defined such that it optimizes the chance of a 
single hit. 



m utant Interaction signa l. Each client system must be signalled when a user interacts with a p.ece of 
con tent ' This can be do^e using something like a package delivery service^ Each time the user 
iriteracts with a piece of content, the system is signalled and the relevance descriptors for that content 
are automatically updated in the meta table. 

Content De scriptors . Each piece of content in the system must be formed to contain a set of 
Sattrib^Ss describing the content. These descriptors are broadcast to each-chert. The client 
s^em wW capture the content descriptors and optionally present them to the consumer for rating. The 
vSttrTbute pairs are determined by the content provider and are input ,nto the broadcast server. 

Exolicit fooHhar* mechanism. Each client system must provide some mechanism for trousers to 
el Zss a ^eLoeioeiihe r receive the specified content or not to rece.ve the specified content 
Users are nolrequired to provide explicit feedback although this option must be present for optimal 
behavior This feeLck mechanism is based soley on trimodal input. Either the user wants the ^content, 
they do not want the content or they express no preference. This mechan.sm may be a s.mple table 
indicating which content is available. 

In order to demonstrate how these pieces fit together, a sample system operation is Presented For the 
oumose of this disclosure, the example system providing video on demand w. I be used. Assume that 
earache Hne Consists of a film. The meta data associated with each film .s m the form of value 
l^MeT^Jhe attribute/value pairs are general and could consist of any number of attnbutes and 
any number of values. 

3.2 Algorithm for broadcast content on demand cache management 
3.2.1 Initial conditions 

For the oumose of this disclosure, assume the system comes pre-loaded from the factory with three 
ca^he elements °f ms) The exact mechanism to bootstrap the content rating table is beyond the scope 
oHhis fnveTon as the policy for maintaining the steao^state system is much more important.. 



Content Description 



Filml 



Film2 



Film3 



Rating 



0 



0 



Rating Type* 



NA 



NA 



NA 



Cached 



Yes 



Yes 



Yes 



Next treatment 



NA 
NA 



NA 



Table TBD: Content rating table 

At this time, we have no inofm ration on how likely the user is to consume any specific cache element so 
the ratings are all zero. 

3 2 2 Content provider assigns meta data to broadcast content , 
The content provider has a set of tools which allow them to associajeirieta data with upcoming 
^^c^mA^li which allow them to produce the required signaling for the system For the 
Hose of thrdisclosure, assume that the domain is films and the meta data consists of canonical 
desertions o? each film such as actors and genre. More complex systems can easily be bu.lt us.ng the 
existing mechanisms.. 

For example, consider the following broadcast content and associated meta data. Each film is modeled 
as a potential cache line. 



Film description 


Attribute 


Value 


Filml 


Actor 


Actor 1 




Genre 


Action 



Table TBD: Sample entry description table for filml 



Film description 


Attribute 


value 


Film2 


s Actor 


Actor 2 




j Genre 


Comedy 



Table 2: Sample entry descrip 



ion table for film2 



Film description 


Attribute 


Value 


Film3 


Actor 


Actor 2 




Genre 


Action 



Table 2: Sample entry description table for film3 



Film description 


Attribute 


Value 


Film4 


Actor 


Actor 1 




Genre 


Comedy 



Table 2: Sample entry descrip 



ion table for film4 



Note that for this example, the film_descriptor is simply a name but in real life, the film would likely be 
represented by a more complex structure such as name, description and possibly a preview video. 

3.2.3 Client receives content descriptors, creates content rating table and meta table 

Assume the client system receives the content descriptors based on the signaling technique described 

in section 2. 

The content rating table is constructed using all items that may be broadcast. For the case of the film 
service, assume that there are a number of films that may be sent. The rating value represents how 
likely the user will be to watch the film. Initially, all ratings are zero: 



Content Description 


Rating 


Rating Type 


Cached 


Next treatment 


Filml 


0 


NA 


Yes 


NA 


Film2 


0 


NA 


Yes 


NA 


Film3 


0 


NA 


Yes 


NA 


Film4 


0 


NA 


No 


NA 



The meta table is contructed with all the attributes present for any of the films. For the running example, 
the following meta table is constructed: 



Attribute 


Value / 


relevance 


Believability 


Actor 


Actor 1 / 


NA 


NA 


Actor 


Actor 2 / 


NA 


NA / 


Genre 


Action \ 


NA 


NA 


Genre 


comedy, \.. 


NA 




Table TBC 


): initial meta-datatahle 



No relevance or believability information is known at this time. 
3.2.4 The user optionally rates the potential content 

The user is optionally presented the ability to request or dismiss potential content. This is not a required 
step as the caching algorithm will work without any explicit user ratings. By allowing this to be an 
optional step, this system promotes scalable interactivity. This means that if users want to interact with 



' the system, they can fine tune to behavior but for consumers who do not wish any more "technical 
interaction", the system can still function. 

For the illustration example, assume the following is presented to the user: 



Content Description 


Treatment (receive/refuse) 


Filml 


Receive (user requested) 


Film2 


Refuse (user requested) 


FilmS 


No action specified 


Film4 


No action specified 



Assume that the user rates iteml and item2. They request to receive filml and not to receive film2. No 
preference is made for films 3 and 4. 

3 2 5 Step7- Update the meta table based on ratings 

For each item that the user requested, the relevance value for all attributes associated with that content 
te ^incremented For each item that is dismissed by the user, the relevance value for all attributes 
associated with the content is decreased. 

For the running example, the following meta table is constructed based on the combination of user input 
and content descriptors. 



Attribute 


Value 


relevance 


Believability 


Actor 


Actor 1 


1 


0 


Actor 


Actor 2 


-1 


0 


Genre 


Action 


1 


0 


Genre 


comedy, ... 


-1 . 


0 



MntP that the relevance rating for each attribute of filjml is incremented (they started at zero) to indicate 
that all (^^icates that the user is interested in this item. Also note that the relevance ^values 
JoffifmS f afe decremented to indicate that data so far suggests the user is not interested in films with 
these qualities. 

Also note that since the user has not actually interacted with any of the content, the believability 
associated with each tuple is not known. 

3 26 Use*consMif£„9i^ , „. ' , ^ 

An mnortant aspect of this system is that the local cache is modelled as a single use (fire and forget) 

when a user accesses a cache line ' they are not likely t0 acces 

same cache line again. 

Assume that the user watches filml . The relevance system now needs to be updated to reflect that fact. 
3 27 Update meta table based on interaction 

Each time the user interacts with the content, the believability of the value attribute pairs for each _ 
H^rinZ n that f m is updated. For value/attribute pairs which have a relevance value greate than 
TX ^abm actor for that attribute is increased (since it accurately served as a predictor or 

wS^S^^^ interact with >- For attributeS wNch haVG 3 rel ! vanc rf IU k- T hp 
betevS value > for this attribute is decreased (since it did not accurately predict which which items the 

user would interact with).. 



For the running example, the meta table now looks like: 



Attribute 


Value \ 


relevance 


Believability 


Actor 


Acton i 


1 


1 


Actor 


Actor 2 


-1 


0 


Genre 


Action 


1 


1 


Genre 


comedy, ... 


-1 


0 


Table TBC 


): meta data table 



Note that the relevence field is not updated for films that have beemmplicitly)related. This must be 
tracked (in the content table) such that the relevance values can ma^e^ogfess. If the user ever 
interacts with a piece of implicitly rated content, rhe relevance values must be adjusted along with the 
believability attributes. 

3.2.8 Update content rating table 

Now that the system has some actual data on what the user will interact with, it needs to go back and 
update the ratings for the existing content. The ratings are based on: 

For each attribute: refevaoce value = attribute_relevance*believability 

For the content: cache rating = average of all attribute relevance values with positive believability 
For example, the rating for film3 is: 



Film 


Attribute 


Value 


Relvance from 
meta table 


Believability from meta 
table 


Component rating 
value 


Film3 


Actor 


Actor 2 


-1 


0 


0 

1 ■ 


Total 


Genre 


Action 


1 


1 


0.5 (average of above) 



Table 2: Temporary cache rating table for film3 
The new content table looks like 



Content Description 


Rating 


Rating Type 


Cache Treatment 


Next treatment 


Filml 


1 


Explicit 


In cache 


Replace 


Film2 


0 


Explicit 


In cache 


Replace 


Film3 


.5 


Implicit 


In cache 




Film4 


.5 


Implicit 




Capture 



IdUIC IUU. wviiwi...«»-» . 

329 Step 14: The user interacts more with the system y~ 

All future interaction results in similar treatment. For exampX *> nsider that tne user watches film3 This 
is an interesting corner case since film3 has not been<atfg>and the relevance values for each "attribute 
have not been updated in the meta table. In this instariceTboth the relevance and the believability items 
must be updated. 



Attribute 


Value 


relevance 


Believability 


Actor 


Actor 1 


1 


1 


Actor 


Actor 2 


-1 


-1 


Genre 


Action 


2 


2 


Genre 


comedy, ... 


-1 


0 


Table TBC 


): meta data table 



Note that since the user watched film3 and since f ilm3 was an action movie, the system is starting to 
rate action movies higher. Since the user dismissed film2 (which has actor 2) but then watched film3 
(which had actor2), the system is now indicating that actor 2 is not a predictor of user behavior. 

3.2.10 Maintaining the most accurate cache lines 

Each time the user interacts with the system, the content table and the meta table are updated. This 
accounts for cases where the user consumes a piece of content as well as cases where they rate a new 
piece of content. By using the meta data describing the upcoming content to be broadcast combined 
with the content rating table (and algorithm), the system can accurately select and acquire the most 
appropriate content. 

4 Advantages over existing systems 

Us j n q a innal broadcast cache allows content providers to manage their network efficiently. This 
invention solves the scalability problems associated with all known existing content on demand systems. 

fi nales across millions . This system will work for a broadcast system with one client and for a broadcast 
svstem with billions of clients. The incremental cost to a service provider for each new user is zero. The 
same content is broadcast (independent of the number of users) as are the same content descriptors. 
Conversely, in a system which requires point to point communication (such as the web or more 
traditional content on-demand systems) also requires content providers to send content to each user 
when requested. Also, a system which maintains relevance on the server requires incremental 
resources for each new user. 

Rr^H^gting thft potential cache list ahead of time allows client systems to prepare for new cache lines 
when they arrive. In a broadcast system, it is possible (and likely) that there are a number of potential 
things to download. By pre-broadcasting all the possible entries ahead of time, the client system can 
determine which resources to collect and when. 

Allows relevant content to be plaved directly from the hard drive rather than streamed over the network, 
which provides better responsiveness and control. 

Rating all potential broadcast items can be used to provide valuable feedback to the service provider . 
See invention disclosure titled: "Driving a broadcast schedule through independent rating systems. 

As long as at least on cache element is attractive to the user, this system provides content on demand . 
In order to be most valuable, the time to consume multiple pieces of content should be greater than the 
time the system needs to provide new content. For example, if we assume that films are broadcast 
every night and we assume that users only watch 1 film per night, the system can maintain a highly 
relevant cache. 

Bv broadcasting the entire pre-broadcast cache, users can see all the content they might possibly get . 
This is in stark contrast to existing video broadcast systems where the users have no idea which content 
the broadcaster has. 

Users are not required to interact with the rating svstem in order to accurately predict relevance. This 
system can work on 100% implicit relevance (based soley on which content the user interacts with or 
can be based on a combination of implicit relevance combined with explicit user feedback. Most of the 
existing relevence systems require input from the user to improve over time. This system infers 
relevance based on the content that the user actually interacts with. 



